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BACKGROUND OF THE INVENTION 
Field of the Invention 

This invention relates to encoding systems and protocols, and more specifically to 
1 0 systems and protocols for establishing a shared secret key for two-way secure 
communications. 
Description of Related Art 

When two parties wish to communicate securely, an efficient mechanism for doing so 
is the use of a shared secret session key, i.e., a key known only to the two parties that 
15 can be used symmetrically to both encrypt and decrypt messages between them for 
the duration of a communication session. Various methods exist to achieve this, and 
each have advantages and disadvantages. 

Parties can use a trusted key authority that distributes the shared secret key to 
each of them separately using their unique key encryption key. However, this 
20 technique requires the storage of keys - i.e., it is not portable with a user, and if a key 
encryption key is compromised the system loses its integrity and past communications 
can be decrypted. 



The "Diffie-Hellman" technique, described in U.S. Pat. No. 4,200,770, 
permits generation of a shared secret key without the use of encryption. Each party 
generates a large random number. By way of example, party A generates the number 
X and party B generates the number Y. Each party sends its number through a 
5 particular kind of one way function and transmits the output. Only knowledge of one 
number (X or Y), and the value of the other number sent through the one-way 
function is sufficient to generate the shared secret key. A drawback of the Diffie- 
Hellman technique is that each side uses a non-shared random number (X or Y) in 
independently generating the shared secret key. A result of the use of non-shared 
1 0 random numbers is that each side performs large exponential and modulo calculations 
when performing one-way functions and generating the shared secret key, resulting in 
a high computational load on both sides. These calculations are required in order to 
make it computationally infeasible for an eavesdropper to combine the two-shared 
numbers in order to obtain the shared secret key. 
1 5 Variations on the Diffie-Hellman technique exist that attempt to make it more 

secure. These variations suffer from the same computational burden as the standard 
Diffie-Hellman technique. For example, U.S. Pat. No. 5,953,424 describes a system 
with a modification of the key generation technique. In addition to the usual Diffie- 
Hellman computations on the original numbers (X and Y) and the transmitted 
20 numbers (which result from calculations), the '424 patent describes extra factors that 
may be combined with the standard Diffie-Hellman factors. These factors are not 
transmitted, so they must be knowable in advance by the communicating parties. 
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Another variation of the Diffie-Hellman technique is disclosed in U.S. Pat. 
No. 5,440,635. In this variant, the transmitted numbers are further encrypted using a 
symmetric key cryptosystem before being transmitted. This doesn't ameliorate any of 
the disadvantages of Diffie-Hellman, noted above. 

A message exchange technique employing a combination of public and private 
key cryptography to communicate a secret key from one party to another is described 
in U.S. Pat. No. 5,241,599. The '599 patent requires that each party share knowledge 
of a secret. A calling party generates a random public key/private key pair, and 
communicates the public key to the called party using their shared secret. The called 
party then communicates the secret key to the calling party using both the public key 
and the shared secret. The technique of the '599 patent suffers from several 
limitations. The calling party must generate a random public key/private key pair, 
which is a costly computation that is often preferably performed by the called party. 
Also, the secret key may be compromised in advance by manipulating the called party 
to affect the secret key it uses or computes. No manipulation or compromise of the 
calling party is required. 

What is needed is a system and method for establishing secure 
communication. 

SUMMARY OF THE INVENTION 
It is an object of the present invention to provide an encoding protocol for 

communicating parties to each obtain a shared secret key. 

One advantage of the present invention is that it is less computationally 

intensive than previous cryptographic systems to obtain a shared secret key. 



Another advantage of the present invention is that the calling party is not 
required to perform any large computations. 

Yet another advantage of the present invention is that it is highly resistant to 
attacks, including eavesdropping, impersonating a party, replay attacks, tampering 
with or probing a party before or after a communications session, and password 
database hijacking. 

Still another advantage of the present invention is that it can be used either 
with or without certificates or physical tokens such as smart cards or biometric 
devices. 

In a method for obtaining a shared secret key according to the present 
invention, a party identifies a first shared random number and a second shared random 
number, and obtains the shared secret key from an output of a combining function 
having a first input including the first shared random number and having a second 
input including the second shared random number. 

In a further aspect of the present invention, the shared secret key is used to 
transform messages. 

In another aspect of the present invention, a party encodes a first shared 
random number, decodes a second shared random number, and obtains the shared 
secret key from an output of a combining function having a first input including the 
first shared random number and having a second input including the second shared 
random number. 

In a further aspect of the present invention, a party encodes a first shared 
random number and a second key using a first key obtained using information 



obtained from a password; decodes a second shared random number using a third key; 
and obtains the shared secret key from an output of a combining function having a 
first input including the first shared random number and having a second input 
including the second shared random number. 
5 In a still further aspect of the present invention, the second key and the third 

key form an asymmetric key pair. 

In another aspect of the present invention, a party decodes a first shared 
random number, encodes a second shared random number, and obtains the shared 
secret key from an output of a combining function having a first input including the 
10 first shared random number and having a second input including the second shared 
random number. 

In a further aspect of the present invention, a party decodes a first shared 
random number and a second key using a first key obtained from information 
obtained from a password, encodes a second shared random number using the second 
1 5 key, and obtains the shared secret key from an output of a combining function having 
a first input including the first shared random number and having a second input 
including the second shared random number. 

In another aspect of the present invention, a party communicates a first shared 
random number and a second shared random number, and obtains the shared secret 
20 key from an output of a combining function having a first input including the first 

shared random number and having a second input including the second shared random 
number. 
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In a further aspect of the present invention, the party communicates an 
asymmetric key and a timestamp with the first shared random number, and a 
timestamp with the second shared random number. 

In still another aspect of the present invention, a device including at least one 
5 processor executes software instructions identifying a first shared random number and 
a second shared random number, and obtains the shared secret key from an output of a 
combining function having a first input including said first shared random number and 
having a second input including said second shared random number. 

In yet another aspect of the present invention, a machine-readable storage 
10 medium contains instructions for a processor, including encoded computer means for 
identifying a first random number, encoded computer means for identifying a second 
random number, and encoded computer means for obtaining the shared secret key 
from an output of a combining function having a first input including said first shared 
random number and having a second input including said second shared random 
15 number. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG la illustrates a peer-to-peer embodiment of the present invention, including 
various embodiments of each peer. 
20 FIG. lb illustrates a client-server embodiment of the present invention, including 
various embodiments of a client. 

FIG. 2 illustrates a sequence of operations performed by a peer, a client, or a server 
according to the present invention. 
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FIG. 3 illustrates a sequence of operations performed by a calling party in a peer-to- 
peer embodiment, or a client in a client-server embodiment of the present invention. 
FIG. 4 illustrates a sequence of operations performed by a called party in a peer-to- 
peer embodiment, or a server in a client-server embodiment of the present invention. 
5 FIG. 5 illustrates a packet that may be used in a signal embodiment of the present 
invention. 

FIG. 6 illustrates a sequence of actions and communications among a user, a calling 
party, and a called party in one embodiment of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

1 0 The present invention provides a system and method for two parties to 

determine a shared secret key. Each party identifies a first shared random number and 
a second shared random number. Then, a combining function is used to obtain a 
shared secret key using the first shared random number and the second shared random 
number. Hence, knowledge of the combining function coupled with knowledge of the 

15 first shared random number and the second shared random number is sufficient to 

obtain the shared secret key. It is preferred, therefore, for the shared random numbers 
to be communicated between the parties without permitting would-be attackers to 
learn both shared random numbers. In some embodiments, this is accomplished by 
using a password. Specifically, each party has access to either information obtained 

20 from a password, or of the password itself. In a preferred embodiment, the password 
is associated with a user. 

A shared secret key may be used along with a symmetric encryption system 
such as IDEA (International Data Encryption Algorithm) in order to efficiently and 
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securely perform communications between two parties. It is desirable that the shared 
secret key be secure and that the two parties authenticate each other, while 
minimizing the computational load necessary to obtain the shared secret key. 

The system and method of the present invention can be implemented in a local 
area network, wide area network, public access network (e.g., Internet), in a network 
of networks such as a hybrid network, or in other communication environments as 
would be apparent. In a network implementation that conforms to the OSI model, the 
shared secret key may be viewed as a session key. In an OSI-compliant embodiment, 
the protocol of the present invention for obtaining a shared secret key resides at layers 
5 and/or 6 of the OSI model, and supports secret key based encoded transport of any 
developer-defined or selected client-server or peer-to-peer protocol. In addition, a 
user authentication graphical user interface (GUI) for any developer-defined 
applications may be provided above the protocol of the present invention, as would be 
apparent. In addition, the protocol of the present invention may be encapsulated 
within another protocol such as a firewall, a virtual private network, or both, or any 
other protocol as would be apparent. With encapsulation, an application benefiting 
from the authentication and encoded transport of the present invention does not need 
to be aware of the details or even the existence of the underlying protocol of the 
present invention. 

In generating a shared secret key according to some embodiments, the system 
and method of the present invention provides a secure and robust user authentication 
protocol, based on asymmetric key encoding. In a preferred embodiment, a first party 
communicates a public key to a second party using information obtained from a 



password associated with a user of the second party. The first and second parties 
exchange shared secret keys which no outside observer can obtain without 
information about the password and information about a private key associated with 
the public key, which is not communicated. 
5 FIG. la and FIG. lb depict exemplary embodiments of the environment of the 

present invention. FIG. la shows an exemplary peer-to-peer embodiment. Users 
101a through lOle and 105a through 105e are graphically depicted as human users for 
ease of representation, although they may be automated entities such as applications, 
daemons, or other electronically-driven users. A user need not be associated with a 

10 particular human if it is a non-human user such as a software-driven user, although it 
can be. Calling users 101 communicate with (i.e., are connected to) exemplary 
calling platforms 102a through 102d, and called users 105 communicate with 
exemplary called platforms 104a through 104d. 

The term 'party' may refer to a user, a platform, or both a user and a platform 

1 5 with which the user is associated. In one embodiment, a calling party is a party that 
initiates a communications session; and a called party is a party that responds to a 
calling party's initiation of a communications session. Network 103 represents any 
network or network of networks, such as the Internet, and may include firewalls, 
virtual private networks, and any kinds of connections (e.g., wireless, Ethernet, etc.), 

20 routers, gateways, protocols, and other components as would be apparent. Exemplary 
platforms 102a and 104a represent laptop computers, which may be connected to 
network 103 via wire-line or wireless connections, as would be apparent. Exemplary 
platforms 102b and 104b represent workstations or personal computers. Exemplary 
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platforms 102c and 104c represent handheld devices. Exemplary platforms 102d and 
104d represent servers, which may be better equipped than the other exemplary 
platforms to handle simultaneous connections to multiple users including remote 
users, as illustrated. Other platforms may be used, such as a dumb terminal, as would 
5 be apparent. For the purposes of this specification, a platform may comprise one or 
more pieces of hardware, a process running on the hardware, a process in memory or 
storage, or a combination thereof. For example, platform 104d may represent the 
physical server, i.e., the hardware comprising the server. Alternatively, platform 104d 
may represent a server process running on the server or in memory on the server. As 

10 an additional alternative, platform 104d may represent a combination of these things. 
A non-human user may be running at least partially on a platform with which it is 
associated, or it may be running completely remotely. The meaning of platform 
varies throughout the specification, and is in each case subject to any of the 
interpretations just enumerated. 

1 5 FIG. la depicts a peer-to-peer configuration, in which a party (possibly 

including one of exemplary users 101a through lOle and/or one of corresponding 
exemplary platforms 102a through 102d) may be either a calling party or a called 
party. Similarly, any of exemplary users 105a through 105e and/or a corresponding 
exemplary platform 104a through 104d, could be either a calling or a called party. 

20 FIG. lb represents a client-server configuration in which a client (possibly including 
one of exemplary users 101a through 101 e and/or one of corresponding exemplary 
platforms 102a through 102d) is the calling party and a party on the server side, 
including user 105d and/or server platform 104d is the called party 105d. The present 
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invention may be used to connect parties, including a calling party and a called party 
to provide for authentication and/or secure communication between the calling party 
and the called party, through network 103. 

A random number has the property that it is difficult for a would-be attacker to 
5 determine the random number without obtaining information characterizing the 
random number. A random number that is either communicated or intended to be 
communicated between a calling party and a called party is referred to as a shared 
random number. In order to communicate a shared random number, a party may send 
or receive the shared random number or information from which the shared random 

1 0 number may be obtained without additional information specific to the shared random 
number and without an astronomical number of computations. A shared random 
number may be sent or received by transmitting or receiving over a communications 
channel or a network information from which the shared random number may be 
easily inferred, such as the shared random number itself. 

1 5 The present invention employs at least two shared random numbers to obtain a 

shared secret key. The shared random numbers are passed through a combining 
function to obtain information used to determine the shared secret key. A combining 
function may be any function, including a compound function, i.e., a function of 
functions, that has a first input including a first number and a second input including a 

20 second number. Additionally, a combining function has the property that knowledge 
of a single input to the combining function does not substantially reduce the difficulty 
of determining an output of the combining function. It is preferred that a combining 
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function be used such that knowledge of a single input to the combining function does 
not reduce the difficulty of determining an output of the combining function at all. 

A benefit of passing shared random numbers through a combining function to 
obtain a shared secret key is that a would-be attacker will be unable to compromise 
5 the shared secret key by obtaining only one random number, either through 

observation or manipulation of a party or its communications, even with knowledge 
of the protocols used and the combining function itself. A combining function may 
involve one or more of a number of operations on its inputs and any parameters that 
might be inherent to the combining function. For example, addition, subtraction, 

10 multiplication, division, exponentiation, logarithms, trigonometric functions, and/or 
modulo operations could be used. A combining function could include a logical 
function, such as OR, AND, NOR, NAND, XOR, and/or XNOR, blending or merging 
(scaling, and then addition), bit shifting, concatenation, truncation, or any 
combinations thereof. Additional operations, conditional operations, and various 

15 combinations of operations, in serial and/or parallel may be used, as would be 

apparent. In a preferred embodiment, an XOR operation is used, which would permit 
the use of a combining function as simple as specifying an output of a combining 
function to be equal to an XOR of two inputs. 

FIG. 2 illustrates a set of steps performed by a party in an embodiment of the 

20 present invention. In step 201 , the party shares a first random number Rl . The 
random number could be shared by being communicated to or from another party, 
possibly through intermediaries. In step 202, the party shares a second random 
number R2. In step 203, the party obtains an output K of a combining function f( ) 
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with a first input including Rl and a second input including R2. In FIGs. 2-4, for ease 
of presentation, an exemplary embodiment of the combining function is shown with 
two inputs consisting of Rl and R2, respectively, yielding K = f(Rl,R2). 

FIG. 3 illustrates a set of steps performed by a calling party in an embodiment 
5 of the present invention. In a client-server embodiment, FIG. 3 illustrates a set of 
steps performed by a client. For ease of description, the party executing the steps in 
FIG. 3 will be referred to as a 'calling party/ which encompasses the term 'client.' In 
step 301, the calling party receives a first shared random number Rl . In step 302, the 
calling party sends a second shared random number R2. In step 203, the calling party 

10 obtains an output K of a combining function f( ) with a first input including Rl and a 
second input including R2. 

FIG. 4 illustrates a set of steps performed by a called party in an embodiment 
of the present invention. In a client-server embodiment, FIG. 4 illustrates a set of 
steps performed by a server. For ease of description, the party executing the steps in 

15 FIG. 4 will be referred to as a 'called party,' which encompasses the term 'server.' In 
step 40 1, the called party sends a first shared random number Rl . In step 402, the 
called party sends a second shared random number R2. In step 203, the called party 
obtains an output K of a combining function f( ) with a first input including Rl and a 
second input including R2. 

20 When a party communicates information, it may do so over network 103. In 

order to send information, the information may be encoded to comply with a 
communications protocol. It may further be encoded with keys, passwords, or 
information derived therefrom. Encoding with keys or passwords or information 
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derived therefrom may comprise encryption, or other forms of transforming data as 
would be apparent. If information is sent through network 103, it may be encoded in 
packets, such as IP packets. An exemplary IP packet is illustrated in FIG. 5. The IP 
packet of FIG. 5 includes an IP header 501 including a source address 502 and a 
5 destination address 503, and embedded data 504 including part of the information sent 
through the network. When a party receives information through network 103, it may 
decode information according to a network protocol, such as the Internet Protocol. 
Information may be decoded with keys or passwords or information derived 
therefrom. Decoding with keys or passwords or information derived therefrom may 
1 0 comprise decryption. Decoding of information may also comprise parsing, in which 
information is extracted from data passed through a network, such as a packet or 
packets. 

Information communicated over network 103 is propagated through network 
103 between communicating parties. Networks may comprise many kinds of links, 
1 5 including wireless links. Signals sent over the network may be embedded in a carrier 
wave, and may be propagated, e.g., as an analog or a digital signal. 

If keys or passwords, including information derived from them are used to 
encode or decode information, then a key or password may itself be encoded. In one 
embodiment, a password is encoded to obtain a 128-bit key. One method of 
20 performing this encoding is as follows. In a first step, lcase() is used to transform all 
alphabetic characters to lower-case. In a second step, characters are transformed 
based on a stored table. In a third step, all bits in the transformed representation of 
each character are concatenated. In a fourth step, the resulting bit stream is repeated 
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until the total bit length is 128. In a fifth step, IDEA is used to encrypt the original 
password using the 128-bit stream as the secret key. In a sixth step, the cyphertext is 
padded to create a 128-bit key, which may be used to encode and/or decode 
information. 

5 The above method for encoding a password is an example of using a one-way 

function. A one-way function has the property that it is computationally infeasible to 
determine an input to the function by using an output of the function. The six-step 
method for encoding the password is equivalent to passing the password through a 
function. In this case, it is a one-way function because the encrypting step makes it 

1 0 computationally infeasible to recover the input by using the output. Another example 
of a one-way function is a hash. 

FIG. 6 illustrates a preferred embodiment of the present invention. The four 
columns of the figure represent users and platforms. Specifically, column 101 
represents a calling party, column 102 represents a calling platform, column 104 

15 represents a called platform, and column 105 represents a called user. Calling user 
101 is connected to calling platform 102, and called user 105 is connected to called 
platform 104. Arrows represent messages sent between the four entities (columns) in 
FIG. 6, and numbers without arrows represent operations that may be performed by 
either or both of the adjacent columns. For example, step 601 represents a message 

20 sent from calling user 101 to calling platform 102, and step 604 represents a step that 
may be performed by called platform 104, called user 105, or both. 

In step 601, calling user 101 sends user identification information (User ID) 
and a password to calling platform 102. The password does not need to be placed in 
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storage on calling platform 102, and could be held in memory on platform 102 just 
long enough for it to fulfil its use. If calling user 101 is a human user, the action of 
sending the User ID and password to platform 102 could be triggered by the action of 
the human user typing in the User ID and password on a keyboard or other 
5 alphanumeric input device. In step 602, calling platform 102 sends information to 
called platform 104 including information obtained from the User ID and information 
concerning a protocol and version that calling platform 102 is capable of using. 

Step 603 is carried out by the calling party, which may comprise calling user 
101, calling platform 102, or both. In step 603, a first key, denoted K user , is generated 

10 using information obtained from the password. In some embodiments, the first key is 
generated as an output of a one way function having an input including the password. 
In other embodiments, other methods of encoding the password may be used to obtain 
Kuser- Other methods may be used to obtain K user , as would be apparent. 

Steps 604 through 606 are carried out by the called party, which may comprise 

15 called platform 104, called user 105, or both. In step 604, the called party identifies a 
first shared random number Rl . This and other identification steps could comprise, 
for example, generating Rl, looking up Rl in a table, obtaining Rl from an external 
source, and/or other methods as would be apparent. In step 605, the called party 
identifies an asymmetric key pair comprising two corresponding asymmetric keys, 

20 e.g., a public key and a private key. For ease of representation, the two asymmetric 
keys are denoted K pub i ic and K private . 

In step 606, a first key, K user , is obtained by using information obtained from 
the User ID. In some client-server embodiments, the first key is obtained by 
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performing a table lookup using information obtained from the User ID. For 
example, one embodiment that uses a first key comprising an encoded password 
requires the called party to have access to a table of passwords, which are indexed by 
User ID. In this way, step 606 may be performed by looking up the password in the 
5 password table using the User ID or information obtained therefrom, and sending the 
password through a one-way function to obtain the first key. Alternatively, the 
password table may contain encrypted or encoded passwords, and a simple table 
lookup may be used to obtain the first key without an extra encoding step. In another 
embodiment, the password table is itself encoded. The table could be encoded as a 

1 0 whole, or it could be broken into sub-tables or fields, with each sub-table or field 

encoded separately. If the password table is encoded, the called party may decode the 
table or a relevant part of it as part of step 606. 

Step 606 may be performed in other ways. For example, in some 
embodiments including a peer-to-peer embodiment, information obtained from the 

1 5 User ID is used to obtain from a trusted third party either the first key or information 
used to generate the first key. 

In step 607, the called party sends the calling party a first message encoded 
with the first key, K user . The first message includes the first shared random number, 
Rl, and one of the two asymmetric keys identified in step 605, which we arbitrarily 

20 denote K pu bii C . The first message also includes a timestamp in some embodiments, 
although in a preferred embodiment timestamps are not used because of timing 
synchronization issues. The first message may be denoted 
K user (Rl ,K pu biic,timestamp). 
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Steps 608 and 609 are performed by the calling party, comprising the calling 
user 101 and/or the calling platform 102. In step 608, the first message is decoded. In 
order to decode the first message, the calling party uses K user . Then, Rl and K pub iic are 
obtained from the first message. One method to obtain Rl and K pu bii c from the first 
5 message is to parse the message, including any header information that may exist. If 
the first message includes a timestamp, then it may be obtained from the first message 
and compared to the actual time. In step 609, a second shared random number R2 is 
identified. 

In step 610, the calling party sends the called party a second message encoded 
10 with the asymmetric key K pub i ic . The second message contains the second shared 
random number R2. The second message also includes a timestamp in some 
embodiments, although in a preferred embodiment timestamps are not used because 
of time synchronization issues. The second message may be denoted 
K pub iic(R2,timestamp). 

1 5 Step 61 1 is carried out by the called party. In step 61 1 , the second message is 

decoded using the other asymmetric key, K priva te, to obtain R2. One method to obtain 
R2 from the second message is to parse the message, including any header 
information that may exist. If the second message includes a timestamp, then it may 
be obtained from the second message and compared to the actual time. 

20 Step 612 is carried out both by the calling party and by the called party. In 

step 612, the shared secret key, K ss , is obtained from an output of a combining 
function having a first input including the first shared random number and a second 
input including the second shared random number. In one embodiment, the shared 
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secret key is the output of a combining function having two inputs consisting of the 
two shared random numbers. This is denoted by K ss = f(Rl,R2). 

In step 613, the two parties communicate using K ss . K ss may be used, e.g., in 
any symmetric encryption system to transform messages. A sender of a message 
5 transforms the message by encoding it using K ss , and a receiver of a message 
transforms the message by decoding it using K ss . 

The present invention may be used with client/server and peer-to-peer 
embodiments. In a peer-to-peer architecture, the called party could also pre-generate 
keys. A problem with peer-to-peer is that password management becomes difficult 
10 because there is no centralized repository. Because password information is 
extremely sensitive, passing passwords becomes a challenge. 

Use of the present invention accrues numerous benefits. One benefit is that 
there is no need to use certificates. Therefore, there is no need to register with 
Certificate Authorities and keep them up to date. This removes an external source of 
15 unnecessary problems - a Certificate Authority's errors. Furthermore, if a user 

wishes to log in to a server using a client-server embodiment of the present invention, 
then any computer logged in to (i.e., used as a client) can immediately have access 
without ensuring that the computer has been registered with a certificate authority. 

Another benefit of the present invention is that in some embodiments keys are 
20 not stored on local computers. In embodiments in which keys are generated 
dynamically, keys never need to be stored on a file system. Storing keys on the 
system allows someone who is capable of compromising a computer to steal the keys, 
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and decrypt messages past, present, or future. In some embodiments of the present 
invention, keys are constantly changed and never stored on a computer's hard drive. 

Yet another benefit of the present invention is that it is not necessary for a 
calling party to generate keys. Generating asymmetric key pairs can be 
5 computationally expensive, resulting in system delays. A calling party may have 
access only to limited computational resources. If an asymmetric key pair is 
generated on a limited machine, connection times between 15 seconds and nearly 2 
minutes are typical using current hardware and algorithms. As keys take more 
computing power to generate, which is likely because the requirements of key size 

10 will increase, the present invention will allow a quick logon time from a 

computationally limited calling party. In some client-server embodiments, a server 
may generate keys constantly (i.e., semi-dynamically). Semi-dynamic key generation 
in a client-server embodiment allows connection latency to be independent of client 
and server hardware requirements. 

15 Still another benefit of the present invention is that human users don ! t need to 

bring anything with them when connecting to another party in a peer-to-peer 
embodiment or logging on in a client-server embodiment. All that a human user 
needs to supply is a password. There is no need for a human user to carry a floppy 
disk with his or her stored "authorized key pair," which reduces the potential for 

20 human error, e.g., an administrator emailing a key pair to a human user. Also, there is 
no need for a human user to have a physical token to log on. This enables true 
mobility by preventing the need for hardware such as a SmartCard reader. 
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A security benefit of the present invention comes from the double integrity of 
the shared secret key. In the present invention, the shared secret key is not sent in a 
single message. The shared secret key is computed based on the values of two shared 
random numbers. The first shared random number is encoded using a function based 
5 on the password. The second shared random number is encoded using a random 

public key. So even if someone were able to somehow steal a user's password, he still 
would have no way to decrypt the messages that the user had transmitted in the past. 
Secure data remains secure. 

The double integrity of the shared secret key adds another benefit: if an 
10 attacker is able to penetrate a party and manipulate it prior to or during a 

communications session, it might in this way be able to weaken, sabotage, specify, or 
intercept a shared random number. However, without the other shared random 
number, the attack would not yield the shared secret key. No attack that targets only 
one shared random number can weaken the shared secret key. 
1 5 The present invention provides strong security protection in obtaining a shared 

secret key. The following are some examples of attacks that are thwarted by the 
system and method of the present invention: 
No password eavesdropping 

No form of the password is ever sent, so one could never obtain the password. 
20 No password database hijacking 

The password database itself is encrypted, so one would never be able to grab 
any form of the password, to launch an off-line password guessing attack. 
No reflection (man-in-the-middle) attack 
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At no point can a message be pulled from one authentication session, and used 
sensibly in a different session, to obtain access to keys or messages. 
No replay attack 

Because of the use of timestamps in some embodiments of the present 
5 invention, it is not possible to use untampered messages to cause either party to 

undergo processing that would ordinarily prohibit a valid user from gaining access to 
the system. 

No impersonating called party 

Impersonating the server would never gain an impersonator access to a 

1 0 password, because no form of the password is ever sent by the calling party. (The 

called party uses a function of the password as a key.). For this matter, it would never 
make sense for an attacker to impersonate the called party. 

The specific algorithms and steps described herein, as well as the basic steps 
which such algorithms represent (even if they are replaced by different algorithms), 

15 are designed for implementation using general purpose microprocessors. 

Furthermore, each of the algorithms and steps described herein, as well as the basic 
steps represented by such algorithms, can be encoded on computer storage media such 
as CD ROMS, floppy disks, computer hard drives, and other magnetic, optical, other 
machine readable media, whether alone or in combination with one or more of the 

20 algorithms and steps described herein. 

Although the methods discussed herein have been described in detail with 
regard to some exemplary embodiments and drawings thereof, it should be apparent 
to those skilled in the art that various adaptations and modifications of the methods 
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can be accomplished without departing from the spirit and the scope of the invention. 
Thus, by way of example and not of limitation, the methods are discussed as 
illustrated by the figures. Accordingly, the invention is not limited to the precise 
embodiments shown in the drawings and described in detail hereinabove, but is set 
out in the following claims. 
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